Server-side recording of a protocol data stream such as the ICA protocol manufactured by Citrix Systems, Inc., of Ft. Lauderdale, Fla., the X protocol by the X.org Foundation, the Virtual Network Computing protocol of AT&T Corp., or the RDP protocol, manufactured by Microsoft Corporation of Redmond, Wash. is useful in authoring training material, providing helpdesk support, enabling tutorials, or for environments where distributing software to each client workstation is cumbersome. However, many conventional methods for recording protocol data streams suffer from drawbacks such as inefficient and lossless encoding of computer screen activity. Recording and storing files solely on the server may create issues regarding the handling of large numbers of concurrent sessions. Many conventional systems typically suffer the drawbacks of recording significantly more data than will ever be reviewed, involving complex recording processes or generating large file sizes.
Some conventional methods for recording protocol data streams are not bound to the remote presentation protocol itself. Many of these solutions involve screen scraping/capture technologies or hooking of the client graphics engine and as a result suffer the drawback of requiring a processor-intensive encoding or transcoding process for playback.
Other methods for recording user screen activity encode graphic output on the client device. Generally, these methods are limited to taking periodic discrete screen snapshots from a Windows client workstation. Microsoft provides a screen capture API as part of Windows Media Encoder SDK but this method may suffer the drawback of focusing on client device recording for the training and video presentation marketplace. Most methods require client-side software components and lack the capacity to perform server-side recording.
Additionally, remote presentation protocols are inherently stateful. In order to view a particular point in a stream of recorded presentation protocol data, playback of the stream must begin from the very beginning of stream and played back sequentially until the particular point is encountered.
Conventional techniques for accessing a recorded stream of data out of sequential order typically involve the use of keyframes and delta frames. Keyframes are typically stored within the stream itself as synchronization points so that frames may be quickly reproduced on a screen. Delta frames typically describe differences from previous frames to produce the visible video frame.
Since remote presentation protocols are typically compact due to their stateful nature, the additional storage of keyframes increases file size by several orders of magnitude. Even with modern digital video compression techniques, keyframes generally add several orders of magnitude to the storage required for a stream of recorded presentation protocol data. However, omitting keyframes results in a non-seekable protocol. A method for seekability without the overhead of oversized files caused by stored keyframes is desirable.